Upgrade Helm Release

The Metrics Server for Kubernetes Dashboard#

If we take a closer look into our Kubernetes Dashboard, especially on the page with listed Pods, we might see that something is missing. To be specific, there are no illustrative curve charts that represent how much CPU and memory are consumed by applications, as givenbelow:

In this lesson, we’ll address this problem and tune our Helm release to show it.

To enable it we need to have the Kubernetes Metrics Server installed in our cluster. This is an application that collects information about resource usage (such as CPU and memory) from the cluster and exposes it using an API. Then an API is consumed by the Dashboard.

Enable the Metrics Server#

There are a couple of ways of deploying the Metrics Server into the cluster. It could be already provided by a public cloud provider or it could be installed with Helm using a separate Helm chart. Luckily for us, we don’t need to use a separate Helm chart. The Metrics Server is already embedded in our Helm chart. We just need to enable it. To learn how to do that, we need to have a look into the values.yaml file and find a part that is responsible for that, as shown below:

Here, two main properties are responsible for enabling Metrics Servers—metricsScraper and metrics-server. By default, both of them are disabled.

Also, please note how descriptive and informative the comments here are. It’s a good practice to put them into a values.yaml file to help the users of a chart figure out what the purpose of each property is. (This advice will come in handy when we start to create our chart.)

Apart from enabling both metricsScraper and metrics-server, we need to add two arguments to the server startup command to skip security protection (since we’re developing everything locally).

With that, we’re ready to apply it to our cluster. But there is a problem here.

The helm install command can be used only when we install a Helm release for the first time. If we want to adjust an already existing one we need to use helm upgrade.

Helm upgrade#

It works very similarly to the helm install command. We can check their definitions (using the --help flag) and see for ourselves that they have a lot in common. Later in this lesson, we’ll explain what the differences between these two are.

Now, let’s upgrade our Helm release:

First, let’s look at the parameters that were provided into the command:

• helm upgrade: This is the basic command for upgrading an already existing Helm release.

• [NAME]: This is the name of the Helm release for which change will be applied; here, it is dashboard.

• [CHART]: This is the name of the Helm chart for which change will be applied; here it is kubernetes-dashboard/kubernetes-dashboard.

Apart from the mandatory arguments, two other parameters were provided, as follows:

• -n monitoring: This is the Kubernetes namespace name where the upgraded Helm release is located.

We can also find two other arguments which are not mandatory, but they make sure that a release will be installed in the interactive widget. These are as follows:

• --install: This makes sure that if a release isn’t installed yet, it will be.

• --create-namespace: This creates a Kubernates namespace if it doesn’t exist.

Validate the Helm release after an update#

Check the Dashboard page#

First, let’s test to see if Metrics are enabled in our Dashboard. To do that, open it in a browser (the hint above the interactive playground will help refresh your memory).

If we go now to the Pods page or the specific Pod view, we can see illustrative charts, as shown below.

Review the history of the releases #

Now, let’s examine our release with Helm CLI. First, let’s see what has changed in the helm list:

Our dashboard Helm release has been bumped up to revision 2.

If we want to check all the revisions we can use a very handy command, helm history:

From the above output, we can see that the 1 revision is now outdated (superseded) and the latest version, 2, has been deployed.

Check the overridden values#

Moreover, we can check what values have been applied to this specific release using the already mentioned helm get command:

This time, however, we don’t use helm get all but the helm get values command which prints only those values that have been provided by us. We can use this command to debug our Helm release, which can be very useful in complex systems.